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Status of this Memo 

This document is an Internet-Draft and is in full conformance with 
all provisions of Section 10 of RFC2026 [1] . 

Internet-Drafts are working documents of the Internet Engineering 
Task Force (IETF), its areas, and its working groups. Note that 
other groups may also distribute working documents as Internet- 
Drafts. 

Internet-Drafts are draft documents valid for a maximum of six months 
and may be updated, replaced, or obsoleted by other documents at any 
time. It is inappropriate to use Internet- Drafts as reference 
material or to cite them other than as "work in progress." 

The list of current Internet-Drafts can be accessed at 
http: //www. ietf .org/ ietf / lid-abstracts . txt 

The list of Internet-Draft Shadow Directories can be accessed at 
http: //www. ietf .org/shadow. html . 



This document describes the use of the SIP INFO Method for 
communicating mid-call events in SIP [1] sessions. Two new MIME 
types are described, according to the rules defined in RFC 2046 [2], 
for use in the INFO message. These media types can be used within a 
SIP INFO message to request, and report, event detection between SIP 
network entities. Emphasis is placed on DTMF signaling to 
communicate user indications when using SIP between a Media Gateway 
Controller (MGC) and a SIP application. 

1 . Introduction 

The SIP INFO method [3] can be used to support interworking between 
the PSTN and SIP networks. It provides a mechanism to carry 
application level information along the SIP signaling path. The SIP 
BCP-T [4] addresses inter MGC (also known as a Softswitch) 
communication using SIP and describes the use of the SIP INFO method 
for carrying mid-session signaling messages. In addition, mid-call 
events, including DTMF signaling, that are detectable by a gateway 
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are necessary for deploying enhanced telephony services in a SIP 
network . 
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This document describes the use of the SIP INFO method, and two MIME 
types, for requesting and reporting events along the SIP signaling 
path. The scenario for PSTN and SIP interworking, where the SIP INFO 
method for event reporting is useful, is in the use of a third party- 
platform that provides enhanced services. The network scenario is 
shown below. 



| MGC | SIP-T | ESP | SIP-T---| MGC | 



I I 

MGCP/Megaco MGCP/Megaco 
I I 



| PSTN | | MG | RTP Session | MG | | PSTN | 



The migration of telecommunications traffic from circuit-based 
networks to packet-based networks will require the interaction of 
"intelligent platforms" with subscriber terminals. The functionality 
described in this document will allow the migration of enhanced 
service platforms (ESPs) to the SIP network. Enhanced services can 
be deployed in network entities other than the MGC, similar to their 
deployment in the PSTN. 

One set of events that is required for enhanced services present in 
the PSTN is the start of DTMF tone and either the end of the DTMF 
tone or the duration of the DTMF tone. DTMF events are of particular 
interest due to the large number of IVR-based applications present in 
the PSTN. Events possible from SIP-enabled terminals such as 
keystrokes are for further study and not addressed in this document. 



2. Existing DTMF Notification Methods 



One of the uses for the SIP INFO method described in the draft [3] is 
carrying DTMF digits generated during a session. The SIP BCP-T 
specifies the use of MIME media types for carrying ISUP and QSIG 
objects (see [5]) and focuses on call set up and tear down. The 
methods derived from this draft for DTMF support are limited to a 
digit string that is collected at the Signaling Gateway (SG). DTMF 
digits are transported in a Q.931 Keypad Facility information element 
as user-to-user data in an ISUP USR message. This method requires 
SIP signaling gateway functionality in the Media Gateway (MG) to 
provide event detection and notification for all access circuit types 
(e.g., ISDN, CAS, and analog). 

Methods have been proposed for carrying telephony events and DTMF in 
the media stream. These methods solve tone distortion due to various 
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vocoders and address the synchronization of the DTMF tones with the 
rest of the media. But for many telephony services, exact 
synchronization is not necessary. The methods also require the SIP 
application to process the media when it is not necessary otherwise. 
In addition, packet loss can be a factor when interested in the 
duration of DTMF tones. 
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Two communications protocols for use between a MG and a MGC do 
provide support for DTMF digit notification, and notification of 
other events detectable by the MG. These are the Media Gateway 
Control Protocol (MGCP) [6] and the Megaco Protocol [7] . However, 
these protocols limit the deployment of enhanced telecommunications 
services to the MGC. The event request and notification do not 
extend past the controlling MGC. It is desirable to deploy enhanced 
telecommunications services within a SIP entity without requiring it 
to have direct control of the MGs or to process the media streams. 

The reliability and order of delivery for DTMF notification by MGCs 
are addressed in [8] . However, the ability of a SIP entity or 
application to request that digit accumulation be performed by the MG 
is not addressed. Nor is the ability to provide a digit mask 
addressed. 

A general method, using the SIP INFO Method, for transporting DTMF 
digits between two SIP entities and for specifying digit collection 
to be performed by a SIP client is described in [9] . This method 
provides a SIP entity with significant control over digit collection 
and detail concerning the results of the collection. The method is 
very useful in a SIP network but requires capabilities outside of the 
MG-to-MGC protocols mentioned above. 

Through support of the application of the SIP INFO Method as 
described in this document by the MGC, event requests and 
notification can take place between a MGC and a SIP network entity. 
Specifically, a SIP entity can request that the MGC enable detection 
of MG supported events and that the MGC pass on event notification 
from the MG to the requesting SIP entity. The use of a Digit Map in 
the event request addresses DTMF accumulation and order of delivery 
issues . 

The use of the SIP INFO Method for DTMF tone reporting also 
eliminates the issues associated with packet loss in the media 
stream. SIP messages can be re-transmitted if not acknowledged by 
the receiving entity. 

3 . DTMF Timing Issues 

Duration of DTMF tones is important to enhanced services, as is the 
length of time a subscriber is allowed to provide information to the 
service. MGCP and Megaco both provide support for tone duration and 
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timers. Support is limited somewhat but what is provided is 
sufficient for existing services. 

MGCP defines a Long Duration Indicator and -an Interdigit Timer. The 
Long Duration Indicator's value is 2 seconds for the DTMF Package. 
That is, keys that are pressed and- held for more than 2 seconds can 
be reported. Event notification will occur when the digit is 
detected (the DTMF digit) and a second notification (the Long 
Duration Indicator) will occur 2 seconds later. The Interdigit 
Timer, defined as 4 seconds, can be used with or without a Digit Map. 
Its function differs when used by itself and with a Digit Map. The 
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two behaviors are T(partial) and T(critical) . The default values are 
16 seconds and 4 seconds respectively, although their values depend 
on specific provisioning within the gateway. The use of these timers 
does provide functionality required by enhanced services. 
Specifically, control over the time a user is given to enter digits, 
and indication of a timeout when waiting for user responses. 

Megaco supports the use of a Long Duration indicator and three timers 
when collecting digits at the gateway. A duration modifier and a 
Start timer, Short timer, and Long timer can be used with a DigitMap. 
The duration modifier is used to detect digits of duration longer 
than the long-duration threshold. The value of the long-duration 
threshold is provisioned in the gateway. The actual tone duration of 
a long duration event will not be known, only that the tone's 
duration exceeded the threshold provisioned in the gateway. The 
three timers are configurable parameters and allow greater 
flexibility than MGCP when waiting for digits. 

4. INFO Method 

SIP INFO messages can be used to specify the events to be reported by 
the MGC. Depending on the protocol used between the MGC and MG, the 
content of the INFO message can be the command parameter used by the 
MGC to specify the events to be detected and reported by the MG. For 
MGCP, the INFO message content would be the RequestedEvents parameter 
used in a Notif icationRequest command. For Megaco, the INFO message 
content would be the EventsDescriptor used in an Add or Modify 
command. 

SIP INFO messages can also be used by the MGC to report events 
detected by the MG. Again, depending on the protocol used between 
the MGC and MG, the content of the INFO message can be the command 
parameter used by the MG to report observed events. For MGCP, the 
content of the INFO message would be the ObservedEvents parameter 
present in the Notify command. For Megaco, the INFO message content 
would be the ObservedEventsDescriptor transmitted in the Notify 
command. 

For both MGCP and Megaco, the event request can be global in scope 
(i.e., for all calls processed by the MG) or on a per call basis. An 
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MG event request that is global in scope is considered unusual for a 
SIP entity and not addressed in this document. 

4.1 Processing Rules 

The processing of INFO messages with message bodies as described in 
this draft should follow those defined in "The SIP INFO Method" [3]. 
If a SIP UA receives an INFO request with a message body that it does 
not understand, it is to respond with a 415 Unsupported Media Type 
message. Specifically, if a MGC receives an event request that it 
does not understand or a MGC to MG protocol that it does not support, 
the MGC can respond to the requesting SIP UA with a 415 Unsupported 
Media Type message. 

The INFO Method ([3]) draft does not specifically mention the 
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behavior for User Agent . Clients that receive INFO requests. The use 
of the INFO Method described in this draft requires that UACs process 
INFO messages in the same manner as UASs. The primary purpose for 
the use of the INFO Method described herein is to allow a services 
platform to request event notification on calls placed to it. 

5 . Proposed Media Types 

Two media types are defined for MGCP and Megaco event requests and 
notifications by the following information: 

Media type name: application 

Media subtype name: mgcp-event/megaco-event 

Required parameters : none 

Optional parameters: version 

Encoding scheme: text 

The media subtype is used to indicate the MGC to MG protocol, either 
mgcp-event or megaco-event . The 'version' parameter is used to 
specify the specific protocol's version. These parameters allow the 
receiving entity to recognize and parse the message correctly. If 
not specified, the default version is assumed to be 1.0 for MGCP and 
1 . 0 for Megaco . 

Encoding the event request and notification in text format is 
specified in this document due to the support for. text encoding of 
message parameters by both MGCP and Megaco. 

A typical header would look like the following: 

Content-Type: application/mgcp-event ; version=1.0 
Content-Transfer-Encoding: text 

5.1 MGCP Event Request 
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The MGCP event request payload is the Request edEvents and optional 
DigitMap parameters defined for MGCP. The request can be any 
combination of events and actions as specified for the 
Re'questedEvents parameter . 

5.2 MGCP Event Notification 

The ObservedEvents parameter present in the MGCP Notify command is 
the payload for the event notification. The notification can be any 
event as specified for the ObservedEvent parameter. 

5 . 3 Megaco Event Request 

The Megaco event request payload is the EventsDescriptor and optional 
DigitMapDescriptor parameters defined for Megaco. The request can be 
any combination of events and actions as specified for the 
EventsDescriptor parameter . 

5.4 Megaco Event Notification 
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The payload for the Megaco event notification is the 

ObservedEventsDescriptor transmitted in the Notify command by the MG 
to the MGC . 

6 . Examples 

The message body of a SIP INFO message used to request that DTMF 
digits be detected and reported follows. The event notification from 
the MG will occur as each DTMF digit is detected. In this example 
the MGCP protocol is used for the MGC to MG communications. 

Content-Type: application/mgcp-event; version=1.0 
Content-Transfer-Encoding: text 

R-. D/ [ 0-9*#A-D] (N) 

The message body of a SIP INFO message used to request that ten DTMF 
digits be accumulated and reported follows, only the digits 0 through 
9 are processed. The event notification from the MG will occur after 
ten digits have been detected or upon timeout. In this example the 
MGCP protocol is used for the MGC to MG communications. 

Content-Type: application/mgcp-event; version=1.0 
Content-Transfer-Encoding: text 

R: D/ [0-9T] (D) 
D: (XXXXXXXXXX) 

The next example is a request for collecting 4 digits using the 
Megago protocol . The event detection requested is from the DTMF 
Detection package. The event notification will occur after 4 digits 
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have been detected or upon timeout. The user is given 5 seconds to 
start entering digits and 5 seconds to enter the next digit. 

Content-Type: application/megaco-event ; version=1.0 
Content-Transfer-Encoding: text 

E=445632 [dd [DM=4digitPIN] ] 

DM=4digitPIN [T:05, S:05, L:16, ( [ 0-9 ] S [ 0-9 ] S [ 0-9 ] S [ 0-9] ) ] 

The message body of a SIP INFO message used to indicate a user has 
pressed the "#" key and held it for longer than 2 seconds follows. 
The MGCP protocol is used for the inter MGC to MG communications. 

Content-Type: application/mgcp-event; version=1.0 
Content-Transfer-Encoding: text 

O: D/#, D/L 

The message body containing a MGCP RequestedEvents parameter asking 
the MG to report a hook flash upon detection follows. 

Content-Type: application/mgcp-event; version=1.0 
Content-Transfer-Encoding: text 
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R: L/[hf] (N) 

7. Practical Considerations 

Support of event notification as described in this draft requires 
some additional protocol support in the MGC and in the SIP UA. 
Considerations for both the MGC and SIP UA are described below. 

7.1 Required MGC Functionality- 
Support of the message bodies described in this draft requires MGC 
functionality as follows. 

When an INFO request is received at the MGC, the MGC is expected to 
perform the conversion of the call identifying parameters in the SIP 
INFO message header to the corresponding parameters in the MGC to MG 
protocol. The MGC can use the same method it uses to correlate a SIP 
BYE request to a MGCP DeleteConnection command or a Megaco Subtract 
command . 

The MGC is expected to format event detection requests into the 
appropriate command for the protocol and MG, then send the command to 
the MG. The MGC is also expected to encode and transmit event 
notifications received from a MG to the requesting SIP UA. This 
requires the MGC to maintain additional state information for the 
call upon receiving an INFO event request so that event notifications 
received from the MG are reported to the SIP UA. 
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Many MGC (Softswitch) manufacturers provide a third-party application 
development environment in which the functionality described in the 
previous two paragraphs can be implemented. 

MGCP defines Endpoints (e.g., DSO, analog line, etc.) and their 
Connections to the packet network. MGCP also states that for some 
Endpoints, MGs should support several Connections between the 
Endpoint and the packet network and that one or more Connections can 
belong to a call. The ability of the MG to support multiple 
Connections (RTP sessions) per Endpoint is not a consideration for 
the event detection and reporting capabilities described in this 
draft. The event detection and reporting of interest is specific to 
the Endpoint and not its Connections. The use of a Package 
designator in the event request also helps reduce any ambiguity in 
which media source event detection and reporting is desired for. 

Megaco defines Contexts and Terminations (RTP Stream, SCN Bearer 
Channel, etc.). Contexts can contain multiple Terminations but a 
Termination can only belong to one Context. A typical "call" handled 
by a MG will involve a single Termination toward the PSTN (although 
it can involve multiple Terminations toward the PSTN) . This 
connection model can present a challenge to SIP entities requesting 
event detection and notification. A call's TerminationID is not 
known beyond the controlling MGC. However, Terminations have 
associated Packages and event requests contain the Package ID. An 
MGC can use the Package specified in the EventDescriptor and RTP 
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session information associated with the SIP Call-ID to determine the 
Terminations for which to request event notification by the MG. The 
Terminations of interest are those that support the specified Package 
(e. g., Tone Detection, DTMF Detection, Call Progress Tones 
Detection) . 

7.2 SIP User Agent Functionality 

SIP User Agents will necessarily have to know how to format and parse 
MGCP and Megaco event requests and notifications. They also need to 
determine which if any MGC-to-MG protocol is supported by the end 
point (MGC) with which it is interacting. It is envisioned that ESPs 
will be deployed in conjunction with "well known" MGCs . In this 
case, the MGC-to-MG protocol can be provisioned in the ESP along with 
other MGC-related criteria. The response to an event notification 
request will also indicate the receiving SIP UA's support of the 
indicated MGC-to-MG protocol. 

A discovery process can be defined by which one SIP UA can determine 
another SIP UA's support of the use of the INFO Method for event 
reporting and its supported MGC-to-MG protocol. The definition of a 
discovery process is outside the scope of this document. 
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8. Security Considerations 



DTMF media types may have security considerations due to customer- 
related information contained in the media types. However, the 
security mechanisms described in RFC 2543 (SIP - Session Initiation 
Protocol) are sufficient to support security of the encapsulated DTMF 
digit information. End-to-end encryption can be used on message 
bodies that contain DTMF digits. No new security considerations are 
thought necessary. 
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